Best Practices
These best practices are guidelines that CygNet suggests you adopt for the DNP3 EIE and the DNP3 Emerson EIE.
Automatic Polling
An integrity poll is automatically performed when the autoPoll property is enabled in the "dnp3 Support" section of the device template file, according to the DNP3 Internal Indication Number (IIN) flags present.
The sample template file provided is defined to meet the following best practices:
- IIN.1, IIN.2, IIN.3 - reads events when the flags indicate class 1, 2, or 3 events are available
- IIN.4 - initiates a time sync when the flag indicates the device needs time
- IIN.7 - performs an integrity poll when the flag indicates a restart
See DNP3 Device Template Items for a sample dnp3 Support structure.
Events
The "Events" data group is designed to be used for regular/scheduled device polling.
When the "Events" data group is polled, CygNet point updates are made to any mapped DEIDs in instantiated data groups with a matching ptId.
Example:
Data group "AnalogIn" has a deid using ptId AI.123, which is mapped to a CygNet point.
When events are polled, if there is an event for ptId AI.123, the CygNet point will be updated accordingly.
When the Event Overflow bit (IIN2.3) is set in the "Internal Indications" data group, it means that events are not being polled often enough. The long term solution is to increase the polling schedule for events. As a stop-gap measure, we recommend issuing the "Integrity Poll" UIS command whenever the Event Overflow flag is set. The UIS command for an integrity poll is predefined in the template file. It requests class 1, 2, and 3 events and then the "All Points (Class 0)" (AllPoints) data group.
Device Compliance Levels
The DNP3 protocol requires that devices meet one of four compliance levels. Some devices using the DNP3 EIE or the DNP3 Emerson EIE may be limited in their functions according to the compliance level of the device.
- Level 1 — the minimum implementation level for communication between a master station and an Intelligent Electronic Device (IED). Includes simple reads and writes and unsolicited messages.
- Level 2 — contains the Level 1 subset plus additional features, such as accepting freeze requests on Binary Counter objects, and parsing read requests for different variation and object combinations, including Binary Input Change objects and Frozen Counter objects. Typical communication is between a master station and a large IED or a small RTU with input and output points local to the device.
- Level 3 — contains the Level 2 subset plus additional features, such as outstation processing of a wider range of read requests, enabling and disabling unsolicited responses for Class 1, Class 2, and Class 3 objects only, and assigning and reassigning data objects to classes dynamically. Typical communication is between a master station and a more advanced RTU.
- Level 4 — contains the Level 3 subset plus additional features, with typical communication between a master station and a medium size outstation. The additional features in Level 4 are self-address reservation, handling object group 0 (device attributes), double-bit input objects, variations with time (frozen counters and events, and AI events), floating point variations for analog input and output, analog input deadband, and events for binary and analog outputs. At this level, the device must provide an XML version of the device profile document containing both the capabilities and current values set in the device.
Note: Devices can implement features from more advanced levels, but can only claim compliance when all requirements for a level are met. A manufacturer can claim compliance for a level as long as a request is handled correctly. For example, Level 1 compliance includes support for analog output values. If the device does not support them, but correctly returns "object unknown", then the device is Level 1 compliant.
For more specific information about DNP3 Implementation levels, see the appropriate manufacturer-provided documentation.

